Systems and methods for optimizing transaction conversion rate using measured feedback

ABSTRACT

A method for optimizing transaction authorization conversion rates using measured feedback includes retrieving payment transaction parameters and authorization results for a plurality of past payment transactions from a database, generating a transaction success model comprising authorization success factors for each of a plurality of payment transaction parameters using data science methods for statistical inference based on the retrieved payment transaction parameters and authorization results, receiving, at an acquirer processor, a payment transaction from a merchant, modifying one or more parameters of the payment transaction according to the generated transaction success model, and submitting the modified payment transaction to a financial institution for processing.

TECHNICAL FIELD

Various embodiments of the present disclosure relate generally to thefield of electronic transaction processing and, more particularly, tooptimizing authorization requests for higher transaction conversionrates.

BACKGROUND

Electronic transactions and networks are used for a great number ofpurchases and sales between merchants and bank card holders. A normalbank card transaction may involve a number of parties, including anaccount holder who possesses a card, a merchant, an acquirer processor,an issuer processor, an issuer financial institution, and a cardassociation network. Millions of such transactions occur daily atmerchants using a variety of payment card types, such as credit cards,debit cards, prepaid cards, and so forth. A transaction based on accountinformation received from an account holder may be declined for a numberof different reasons, such as insufficient funds, card expiration,expired account information, or a variety of other occurrences. However,additional factors, such as the presence or absence of some items ofaccount information, may also affect the rate of acceptance, orconversion, of payment transactions. Declined transactions may lead to avariety of undesirable outcomes for the merchant and the account holder.Conventional methods for submitting electronic transactions may submitsuch transactions according to factors specific to the acquirerprocessor or to the merchant, but do not consider factors that might beshown to affect transaction conversion in past transactions.

The present disclosure is directed to overcoming one or more of theseabove-referenced challenges.

SUMMARY OF THE DISCLOSURE

According to certain aspects of the present disclosure, systems andmethods are disclosed for optimizing transaction authorizationconversion rates using measured feedback.

In one embodiment, a computer-implemented method is disclosed foroptimizing transaction authorization conversion rates using measuredfeedback. The method includes: retrieving payment transaction parametersand authorization results for a plurality of past payment transactionsfrom a database, generating a transaction success model comprisingauthorization success factors for each of a plurality of paymenttransaction parameters using data science methods for statisticalinference based on the retrieved payment transaction parameters andauthorization results, receiving, at an acquirer processor, a paymenttransaction from a merchant, modifying one or more parameters of thepayment transaction according to the generated transaction successmodel, and submitting the modified payment transaction to a financialinstitution for processing.

In accordance with another embodiment, a system is disclosed foroptimizing transaction authorization conversion rates using measuredfeedback. The system comprises: a memory having processor-readableinstructions stored therein; and a processor configured to access thememory and execute the processor-readable instructions, which whenexecuted by the processor configures the processor to perform aplurality of functions, including functions to: retrieve paymenttransaction parameters and authorization results for a plurality of pastpayment transactions, generate a transaction success model comprisingauthorization success factors for each of a plurality of paymenttransaction parameters using data science methods for statisticalinference based on the retrieved payment transaction parameters andauthorization results, receive, at an acquirer processor, a paymenttransaction from a merchant, modify one or more parameters of thepayment transaction according to the generated transaction successmodel, and submit the modified payment transaction to a financialinstitution for processing.

In accordance with another embodiment, a non-transitory machine-readablemedium is disclosed that stores instructions that, when executed by acomputer, cause the computer to perform a method for optimizingtransaction authorization conversion rates using measured feedback. Themethod includes: retrieving payment transaction parameters andauthorization results for a plurality of past payment transactions froma database, generating a transaction success model comprisingauthorization success factors for each of a plurality of paymenttransaction parameters using data science methods for statisticalinference based on the retrieved payment transaction parameters andauthorization results, receiving, at an acquirer processor, a paymenttransaction from a merchant, modifying one or more parameters of thepayment transaction according to the generated transaction successmodel, and submitting the modified payment transaction to a financialinstitution for processing.

Additional objects and advantages of the disclosed embodiments will beset forth in part in the description that follows, and in part will beapparent from the description, or may be learned by practice of thedisclosed embodiments. The objects and advantages on the disclosedembodiments will be realized and attained by means of the elements andcombinations particularly pointed out in the appended claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the detailed embodiments, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate various exemplary embodiments andtogether with the description, serve to explain the principles of thedisclosed embodiments.

FIG. 1 depicts a block diagram of an example payment system and networkin which optimizing transaction authorization conversion rates usingmeasured feedback is performed, according to one or more embodiments.

FIG. 2 depicts a dataset of processing results, according to one or moreembodiments.

FIG. 3 depicts a block diagram of an example process logic flow foroptimizing transaction authorization conversion rates using measuredfeedback, according to one or more embodiments.

FIG. 4 is a flow chart depicting an example process for optimizingtransaction authorization conversion rates using measured feedback,according to one or more embodiments.

FIG. 5 depicts a block diagram of an example system and process flow foroptimizing transaction authorization conversion rates using measuredfeedback, according to one or more embodiments.

FIG. 6 depicts a block diagram of an example process logic flow andmodules for optimizing transaction authorization conversion rates usingmeasured feedback, according to one or more embodiments.

FIG. 7 depicts a computing device for optimizing transactionauthorization conversion rates using measured feedback, according to oneor more embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS

While principles of the present disclosure are described herein withreference to illustrative embodiments for particular applications, itshould be understood that the disclosure is not limited thereto. Thosehaving ordinary skill in the art and access to the teachings providedherein will recognize additional modifications, applications,embodiments, and substitution of equivalents all fall within the scopeof the embodiments described herein. Accordingly, the invention is notto be considered as limited by the foregoing description.

Various non-limiting embodiments of the present disclosure will now bedescribed to provide an overall understanding of the principles of thestructure, function, and use of systems and methods disclosed herein forthe scheduling of transaction payment requests.

For simplicity, the description that follows will be provided byreference to a “payment vehicle,” which generally refers to any type offinancial alternative to currency. As is to be clear to those skilled inthe art, no aspect of the present disclosure is limited to a specifictype of payment vehicle. Therefore, it is intended that the followingdescription encompasses the use of the present disclosed techniques withmany other forms of financial alternatives to currency, including creditcards, debit cards, smart cards, single-use cards, pre-paid cards,electronic currency (such as might be provided through a cellulartelephone or personal digital assistant), and the like. Payment vehiclesmay be traditional plastic transaction cards, titanium-containing, orother metal-containing, transaction cards, clear and/or translucenttransaction cards, foldable or otherwise unconventionally-sizedtransaction cards, radio-frequency enabled transaction cards, or othertypes of transaction cards, such as credit, charge, debit, pre-paid orstored-value cards, or any other like financial transaction instrument.A payment vehicle may also have electronic functionality provided by anetwork of electronic circuitry that is printed or otherwiseincorporated onto or within the payment vehicle (and typically referredto as a “smart card”), or be a fob having a transponder and an RFIDreader, or may operate as a mobile wallet or by near field communication(NFC).

As described above, declined transaction payment requests may lead toundesirable outcomes, and associated increased costs, for merchants andaccount holders. Thus, the embodiments of the present disclosure aredirected to improving (i.e., increasing) the successful authorization oftransaction payment requests.

In accordance with one or more embodiments, and as described in moredetail below, an acquirer processor may maintain a database of pasttransactions and the associated authorization results. Analysis of thesetransaction results by statistical methods or other means may be used todetermine patterns of acceptance or denial of transaction paymentrequests based on factors associated with the transactions, including,for example, presence of a billing address, presence of a cardverification code (CVV), the merchant categorization code (MCC),presence of an expiration date, etc. The transaction may be modifiedwith respect to these factors, as determined at least in part by such ananalysis of historical authorization success rates. According to one ormore embodiments, a modified authorization request may be submitted tothe payment network.

One or more examples of these non-limiting embodiments are illustratedin the selected examples disclosed and described in detail withreference to FIGS. 1-7 in the accompanying drawings. Those of ordinaryskill in the art will understand that systems and methods specificallydescribed herein and illustrated in the accompanying drawings arenon-limiting embodiments. The features illustrated or described inconnection with one non-limiting embodiment may be combined with thefeatures of other non-limiting embodiments. Such modifications andvariations are intended to be included within the scope of the presentdisclosure.

FIG. 1 depicts a block diagram of an example payment environment 100 foroptimizing transaction authorization conversion rates. In the examplepayment environment 100, a payment vehicle 126 (e.g., a credit card) maybe issued to an account holder 113 by an issuer financial institution114. Issuer financial institution 114 may be any of a variety offinancial institutions that is capable of issuing a payment vehicle toan account holder. Payment vehicle 126 may be used to pay a merchant 116for a purchase transaction at a merchant point of sale (POS) device 118.Merchant POS device 118 may be any device that facilitates receipt of apayment vehicle for payment of a purchase, such as for example, a POSterminal or a web interface. Further, merchant 116 may be any type ofmerchant or service provider, such as, for example, a brick-and-mortarmerchant, an online merchant, a mobile merchant, a kiosk, or any othertype of merchant or device configured to receive payment cards, orelectronic or mobile wallets, from account holders as a form of payment.

POS device 118 may be configured to interact with payment vehicle 126 toobtain account information about a consumer account affiliated withaccount holder 113. As shown in the depicted callout of POS device 118,in one or more embodiments, POS device 118 may include a memory 167coupled to processor 151, which may control the operations of a reader163, an input device 153, an output device 165, and a network interface161. Memory 167 may store instructions for processor 151 and/or data,such as, for example, an identifier that is associated with merchantaccount 112.

In one or more embodiments, reader 163 may include a magnetic stripreader. In one or more embodiments, reader 163 may include a contactlessreader, such as, for example, a radio frequency identification (RFID)reader, a near field communications (NFC) device configured to read datavia magnetic field coupling (in accordance with ISO standard 14443/NFC),a Bluetooth transceiver, a Wi-Fi transceiver, an infrared transceiver, alaser scanner, and so forth.

In one or more embodiments, input device 153 may include key buttonsthat may be used to enter the account information directly into POSdevice 118 without the physical presence of payment vehicle 126. Inputdevice 153 may be configured to provide further information to initiatea transaction, such as, for example, a personal identification number(PIN), password, zip code, etc., or in combination with the accountinformation obtained from payment vehicle 126. In one or moreembodiments, output device 165 may include a display, a speaker, and/ora printer to present information, such as, for example, the result of anauthorization request, a receipt for the transaction, an advertisement,and so forth.

In one or more embodiments, network interface 161 may be configured tocommunicate with acquirer processor 122 such as, for example, via atelephone connection, an Internet connection, or a dedicated datacommunication channel.

In one or more embodiments, the instructions stored in memory 167 may beconfigured at least to cause POS device 118 to send an authorizationrequest message to acquirer processor 122 to initiate a transaction. POSdevice 118 may or may not send a separate request for the clearing andsettling of the transaction. The instructions stored in memory 167 alsomay be configured to cause POS device 118 to perform other types offunctions discussed in this description.

In one or more embodiments, POS device 118 may have fewer componentsthan those illustrated in FIG. 1 . For example, in one or moreembodiments, POS device 118 may be configured for “card-not-present”transactions; and POS device 118 may not have a reader 163. In one ormore embodiments, POS device 118 may have more components than thoseillustrated in FIG. 1 .

During a purchase event, merchant POS device 118 may send anauthorization request 120 for the purchase transaction to acquirerprocessor 122 that processes payment vehicle transactions for merchant116. Additional intermediary entities, such as one or more paymentgateways, may assist with the handling and routing of authorizationrequest 120 or other related messaging. For the purposes ofillustration, such intermediary entities may be considered part ofacquirer processor 122. Authorization request 120 may includeidentifying information from payment vehicle 126, such as a BIN number,an expiration date, and a first and last name of the account holder, forexample. Authorization request 120 may further include identifyinginformation from the purchase, such as an amount and identifyinginformation from merchant POS device 118 and/or merchant 116, forexample.

In one or more embodiments, payment vehicle 126 may be used to establisha recurring billing arrangement between account holder 113 and merchant116. An initial transaction may allow merchant 116 to store accountinformation that may be used for subsequent billing events. The accountinformation may be stored in a cards-on-file storage 136. For example,the purchase event illustrated in FIG. 1 may be associated with asubscription, membership plan, installment payment plan between merchant116 and account holder 113, and so on. For subsequent transactions,merchant 116 may access cards-on-file storage 136 to retrieve therelevant account information. The subsequent transactions may notrequire direct involvement from account holder 113. In one or moreembodiments, account holder 113 may trigger the subsequent transaction,but may not provide payment vehicle 126 to merchant 116, as merchant 116may access the cardholder's account information in cards-on-file storage136.

A payment processing computing system 124 at acquirer processor 122 mayreceive authorization request 120 from merchant 116. Payment processingcomputing system 124 may translate authorization request 120, ifnecessary, and may provide authorization request 120 to a paymentnetwork 142. Payment network 142 may be, for example, a network of acredit card association affiliated with payment vehicle 126. Nonlimitingexamples of credit card associations include VISA, MASTERCARD, DISCOVER,and AMERICAN EXPRESS, and so on. Authorization request 120 then may beprovided to a payment processing computing system 128 at an issuerprocessor 130. In response to receiving the authorization request, andbased on the type of payment vehicle 126, payment processing computingsystem 128 may provide authorization request 120 to issuer financialinstitution 114. Using information from authorization request 120,issuer financial institution 114 may associate the purchase transactionwith an account 131 of account holder 113 held by issuer financialinstitution 114. Issuer financial institution 114 then may send anauthorization response 132 which may either approve or deny thetransaction. Authorization response 132 may be provided to paymentprocessing computing system 128 at issuer processor 130 and thenprovided to payment network 142. Authorization response 132 then may beprovided to payment processing computing system 124 at acquirerprocessor 122. Upon receiving authorization response 132, paymentprocessing computing system 124 may send either an approval message or adenial message to merchant POS device 118 to complete the purchasetransaction. If the purchase transaction is approved, it may be postedto account holder's account 131 and reconciled later with account holder113 and merchant 116.

Transaction records may be stored in one or more locations within system100. In one or more embodiments, the transaction record may be storedwithin a transaction data database 134 of acquirer processor 122. Thetransaction data may be received by transaction data database 134 fromvarious sources, such as merchant POS device 118, merchant 116, acquirerprocessor 122, and so on. A plurality of transaction parametersassociated with the purchase transaction may be stored in eachtransaction record, which may generally be used for settlement andfinancial recordkeeping. While the transaction parameters stored in eachtransaction record may vary, example transaction parameters may include,without limitation, account number, card number, payment vehicleinformation, product information (such as product type, product serialnumber, and so forth), loyalty account information, merchantinformation, transaction amount, response code, transaction date,transaction time, whether the transaction was a “card present”transaction, and so on.

FIG. 2 depicts a dataset of processing results, according to one or moreembodiments. Dataset of processing results 134 may include historicaltransaction information that may be processed and analyzed in order tooptimize transaction conversion rates, as shown in FIG. 3 , based on,for example, an analysis of trends and/or correlations. Dataset 134 mayinclude transaction parameters 220 such as, for example, a billingaddress 222, a card verification value (CVV) 224, a payment processingnetwork 226, a payment vehicle expiration date 228, a payment vehicleissuer token 230, a merchant classification code (MCC) 236, andadditional parameters 238. Dataset 134 may also include an authorizationresult 240, which may indicate whether the particular combination oftransaction parameters 220 led to an authorization (232) and a reasonresponse code (RRC) related to the authorization result (234). Further,while dataset of processing results 134 may include many differenttransaction parameters 220, in some embodiments only a subset of theparameters may be used for optimizing transaction authorizationconversion rates.

FIG. 3 depicts a block diagram of an example process logic flow foroptimizing transaction authorization conversion rates, according to oneor more embodiments. As shown in FIG. 3 , a process for optimizingtransaction authorization conversion rates may include identifyingfactors for authorization of transaction requests to produce a databaseof transaction requests 134. For example, such identification mayinclude applying data science methods 310 to database of transactionrequests 134. However, other methods may be used such as machinelearning, etc. Database of transaction requests 134 may further includeinformation produced by performance manager 355 based on factor successdata, possibly in conjunction with a process or generating and updatingfactor success data 360, such as data science inference of conversionfactors 310. Data science engine 310 performing an inference ofconversion factors may use measured feedback to process transaction datastored in transaction request database 134 in order to generate factorsuccess data 360. For example, data science engine 310 may performstatistical inference techniques on the transactions contained in thedataset of processing results in order to determine a transactionsuccess model. Factor success data 360 may aggregate test and controlgroups. Data stored in factor success data 360 may be used to determinethe effectiveness of optimizing transaction requests, such as bycomparing results for optimized transactions (test transactions) andnon-optimized transactions (control transaction). Such a determinationmay be specific to particular factors employed for optimization of testtransactions. Factor success data may further include measurement, forexample, at the level of the specific issuer and account range(generally associated with a card product of a particular issuer), ofthe sensitivity of a factor. That is, an assessment of whether amanipulation (inclusion, exclusion, alteration) of a factor resulted inan improvement or decrease in the rate of authorization approvals atthat issuer/account range. Performance manager 355 may automaticallycalibrate optimization factors employed by rules engine 345 throughanalysis of factor success data 360 and transaction scenarios stored indataset of processing results 134. Performance management may include,for example, the modification of prior rules based on continuingassessment of the results from transactions sent to the issuer/accountrange. It may include and take into account negative results besides theauthorization denial, such as an increase in the rate of chargebacks orfraud alerts generated by the issuer. These negative effects may occur,for example, even if the authorization is approved.

A merchant, such as merchant 116 depicted in FIG. 1 , may submit atransaction request, such as authorization request 120 depicted in FIG.1 , to acquirer processor 122. The transaction request may beinterpreted by rules engine 345 of the acquirer processor based on thedatabase of transaction requests and the factor success data. Thetransaction request may be re-formatted by an authorization formattingservice, such as authorization formatting service 350 and 330 prior tobeing submitted to a payment network. Re-formatting of transactionrequests may be performed, for example, in batch, in a queue oftransaction requests, asynchronously, or in real time as a managedservice, such as managed service 330 depicted in FIG. 3 , etc. Thetransaction processing by the acquirer processor may also includevalidation and reporting functions, such as A/B testing and reporting ofauthorization success metrics 340.

FIG. 4 is a flow chart depicting an example process for optimizingtransaction authorization conversion rates, according to one or moreembodiments. As shown in FIG. 4 , at operation 405, acquirer processor122 may generate factor success data, such as factor success data 360depicted in FIG. 3 , from a dataset of processing results, such astransaction database 134 depicted in FIG. 1 . The factor success datamay be generated statistical inference methods executed by a datascience engine, such as data science engine 310 depicted in FIG. 3 . Forexample, the data science engine may perform statistical inferencetechniques on the transactions contained in the dataset of processingresults in order to determine a transaction success model. At operation410, acquirer processor 122 may receive a payment transaction from amerchant, such as merchant 116 depicted in FIG. 1 . The paymenttransaction may include, in addition to a transaction amount, primaryaccount identifier, customer identification, etc., for example, abilling address, a card verification value (CVV), a payment processingnetwork, a payment vehicle expiration date, a payment vehicle issuertoken, a merchant classification code (MCC), and additional parameters.At operation 415, acquirer processor 122 may determine parameters of thepayment transaction, such as authorization request 120 depicted in FIG.1 . Determining the parameters of the payment transaction may includeidentifying parameters that are not present in the transaction, such asthe CVV, expiration data, billing address, etc. At operation 420,acquirer processor 122 may compare one or more parameters of the paymenttransaction to the factor success data. Such comparison may includeapplying factor weights from the factor success data to the parametersof the transaction. Such factor weights may be determined by datascience engine 310 by any suitable method, including, for example,logistic regression, probit regression, maximum likelihood estimation,iteratively reweighted least squares, etc. At operation 425, acquirerprocessor 122 may modify the parameters of the payment transactionaccording to the factor success data. At operation 430, acquirerprocessor 122 may submit the modified transaction for processing by anissuer processor, such as issuer processor 130 depicted in FIG. 1 . Atoperation 435, acquirer processor 122 may receive a transactionauthorization result from the issuer processor. At operation 440,acquirer processor 122 may add the transaction authorization result andthe parameters of the payment transaction to the dataset of processingresults. The process may then resume at operation 405 in order toprocess subsequent transactions.

FIG. 5 depicts a block diagram of an example process flow for optimizingtransaction authorization conversion rates, according to one or moreembodiments. A payment transaction 506 may be received from a merchant502 by an acquirer processor 508. Payment transaction 506 may be basedon account information 504 maintained by merchant 502, or elsewhere, asmay be appropriate. Payment transaction 506 may include typicaltransaction data, such as, for example, an amount, an accountidentifier, a billing address, a card verification value (CVV), apayment vehicle expiration date, a payment vehicle issuer token, amerchant classification code (MCC), etc. At least some of thetransaction data transmitted in the payment transaction may include datathat was originally received by merchant 502 during an initial paymenttransaction originating with a payment vehicle and stored in acards-on-file storage 136, for example. A payment processing computingsystem of acquirer processor 508 may determine the card association thatis affiliated with the payment transaction 506 (e.g., VISA, MASTERCARD,and so forth), to determine the proper processing channels for thetransaction such as, for example, a payment processing network.

Acquirer processor 508 may transmit an authorization attempt ortransaction request 514 to a payment network, which in turn may transmittransaction request 516 to an issuer financial institution 518. Issuerfinancial institution 518 may approve or reject the authorizationrequest based on a status of a financial account 530 associated with thetransaction or cardholder, or other factors, such as, for example, thepresence or absence of a billing address, the presence or absence of acard verification value (CVV), the presence or absence of a paymentvehicle expiration date, the presence or absence of a payment vehicleissuer token, a merchant classification code (MCC), a selection of apayment processing network, etc. Generally, all authorization requestsinclude an MCC, however some issuing banks view certain MCCs as riskierthan others and therefore the selection of which MCC to include in theauthorization requests—assuming the merchant qualifies for more thanone—can influence the approval. Acquirer processor 508 may communicatethe authorization result of transaction request 516 to merchant 502 by,for example, an authorization response 507. Financial account 530 can beany suitable account, such as a DDA account, a gift card account, aprepaid account, or any other type of account that can be linked to oraccessed by payment vehicle. The available account balance of financialaccount 530 may vary over time as the account holder withdraws funds anddeposits funds. Transaction requests may be rejected, for example, forreasons associated with financial account 530, such as non-sufficientfunds, out-of-date account information, parameters provided with orabsent from the transaction request etc. Acquirer processor 508 maystore factors associated with transaction request 516 in dataset ofprocessing results 134 that may be used to determine a likelihood ofauthorization or conversion for subsequent transaction requests. Asdescribed above with respect to FIG. 2 , factors associated withtransaction request 516 may include, for example, billing address 222,card verification value (CVV) 224, payment processing network 226,payment vehicle expiration date 228, payment vehicle issuer token 230,merchant classification code (MCC) 236, additional parameters 238,reason response code (RRC) 234, and so forth. In accordance with one ormore embodiments, acquirer processor 508 may, as discussed in greaterdetail below in reference to FIG. 6 , include performance manager 355,data science engine 310, and rules engine 345, to process paymenttransaction 506 based on transaction data 134 and factor success data360. Acquirer processor 508 may further include an authorizationformatting engine 350 to appropriately modify payment transaction 506based on the processing of payment transaction 506.

FIG. 6 depicts a block diagram of an example process logic flow andmodules for optimizing transaction authorization conversion rates,according to one or more embodiments. As shown in FIG. 6 , acquirerprocessor 508 may receive payment transaction 506. Payment transaction506 may include transaction data such as, for example, a billing address622, a card verification value (CVV) 624, a payment processing network626, a payment vehicle expiration date 628, a payment vehicle issuertoken 630, a merchant classification code (MCC) 636. Payment transaction506 may include additional parameters not shown in FIG. 6 . Rules engine345 of acquirer processor 508 may take in the transaction data forprocessing. Such processing may include querying dataset of processingresults 134 for other potentially corresponding transactions. Factorsuccess data 360 may be generated using data science methods forstatistical inference performed by data science engine 310. For example,data science engine 310 may execute a statistical inference analysis inwhich the data science engine may process the transactions contained indataset of processing results 134 in order to determine a transactionsuccess model that may comprise the weighted factors to be stored in thefactor success data. In addition, data science engine 310 may assess thesignificance of the success factors by any suitable means, such as, forexample, a likelihood ratio test, computation of the Wald statistic,etc. Rules engine 345 may further read factor success metrics fromfactor success data 360. Based on the corresponding transaction datareceived from dataset of processing results 134 and the factor successmetrics from factor success data 360, rules engine 345 may invokelearning engine 320 to execute an application phase in which thetransaction success model is applied to the parameters of the paymenttransaction to determine whether the likelihood of obtainingauthorization for payment transaction 506 from issuer financialinstitution 518 may be improved by altering the presentation of one ormore aspects of the transaction data. For example, rules engine 345 maydetermine that presentation of payment transaction 506 without billingaddress information may improve the likelihood of obtainingauthorization. In particular, transaction data received from dataset ofprocessing results 134 and the factor success metrics from factorsuccess data 360 may indicate that the issuer financial institution 518may issue two responses: one indicating overall approval or denial, andone indicating whether a supplied billing address matches a billingaddress on file with the issuer financial institution 518. If issuerfinancial institution 518 is known to authorize transactions lacking abilling address and deny transactions having a mismatched address, thenpresenting payment transaction 506 without billing address 622 mayimprove the likelihood of obtaining authorization. Similarly,transaction data received from dataset of processing results 134 and thefactor success metrics from factor success data 360 may indicate thatomitting CVV 624 or expiration date 628 when presenting paymenttransaction 506 may improve the likelihood of obtaining authorization.In addition, a merchant may qualify for multiple different MCCs based onthe nature of the businesses conducted by the merchant. Transaction datareceived from dataset of processing results 134 and the factor successmetrics from factor success data 360 may indicate that one of theavailable MCCs may have a greater likelihood of obtaining authorization.Rules engine 345 may, accordingly, present payment transaction 506 withthe MCC with the greatest likelihood of obtaining authorization.Likewise, transaction request 506 may have multiple payment networks 532available for submission to issuer financial institution 518 forprocessing. Transaction data received from dataset of processing results134 and the factor success metrics from factor success data 360 mayindicate that one of the available payment networks 532 may yield agreater likelihood of obtaining authorization. Rules engine 345 may,accordingly, select the payment network with the greatest likelihood ofobtaining authorization. Finally, some payment vehicles may havetransaction tokens available associated with prior authorization ofpayment transactions or including encrypted payment or authorizationcredentials. Presentation of payment transaction 506 with such a tokenmay improve the likelihood of obtaining authorization. Where transactiondata received from dataset of processing results 134 and the factorsuccess metrics from factor success data 360 indicate that presentationof a token may improve the likelihood of obtaining authorization, rulesengine 345 may include an available token with transaction request 506.

Upon completing the processing of payment transaction, rules engine 345may invoke authorization formatting engine 350 to appropriately modifypayment transaction 506 based on the processing of payment transaction506. Authorization formatting engine 350 may generate a modifiedtransaction request 514 to be submitted to issuer financial institution518 by way of payment network 514.

The processes described herein may be performed on or between one ormore computing devices that are specially configured to perform theprocessing described herein. Referring now to FIG. 7 , an examplecomputing device 700 is presented. A computing device 700 may be, forexample, a server, a computing device that is integrated with othersystems or subsystems, a mobile computing device, a cloud-basedcomputing capability, and so forth. The computing device 700 can be anysuitable computing device as would be understood in the art, includingwithout limitation, for example, a custom chip, an embedded processingdevice, a tablet computing device, a POS device 118, a paymentprocessing computing system 124, a payment processing computing system128, a personal data assistant (PDA), a desktop, a laptop, amicrocomputer, a minicomputer, a server, a mainframe, or any othersuitable programmable device. According to one or more embodiments, asingle component can be replaced by multiple components and multiplecomponents can be replaced by a single component to perform a givenfunction or functions. Except where such substitution would not beoperative, such substitution is within the intended scope of the one ormore embodiments.

The computing device 700 may include a processor 702 that may be anysuitable type of processing unit such as, for example, a general purposecentral processing unit (CPU), a reduced instruction set computer(RISC), a processor that has a pipeline or multiple processingcapability including having multiple cores, a complex instruction setcomputer (CISC), a digital signal processor (DSP), an applicationspecific integrated circuits (ASIC), a programmable logic devices (PLD),and a field programmable gate array (FPGA), among others. The computingresources may further include, for example, distributed computingdevices, cloud computing resources, and virtual computing resources ingeneral, etc.

The computing device 700 also may include one or more memories 706 suchas, for example, read only memory (ROM), random access memory (RAM),cache memory associated with the processor 702, or other memories suchas dynamic RAM (DRAM), static ram (SRAM), programmable ROM (PROM),electrically erasable PROM (EEPROM), flash memory, a removable memorycard or disk, a solid state drive, and so forth. The computing device700 also may include storage media such as, for example, a storagedevice that can be configured to have multiple modules, such as magneticdisk drives, floppy drives, tape drives, hard drives, optical drives andmedia, magneto-optical drives and media, compact disk drives, CompactDisk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), CompactDisk Rewriteable (CD-RW), a suitable type of Digital Versatile Disk(DVD) or BluRay disk, and so forth. Storage media such as flash drives,solid state hard drives, redundant array of individual disks (RAID),virtual drives, networked drives and other memory means includingstorage media on the processor 702, or memories 706 are alsocontemplated as storage devices. It can be appreciated that such memorycan be internal or external with respect to operation of the disclosedembodiments. It can be appreciated that certain portions of theprocesses described herein may be performed using instructions stored ona non-transitory computer-readable medium or media that direct acomputer system to perform the process steps. Non-transitorycomputer-readable media, as used herein, comprises all computer-readablemedia except for transitory, propagating signals.

Network and communication interfaces 712 may be configured to transmitto, or receive data from, other computing devices 700 across a network714. The network and communication interfaces 712 may be, for example,an Ethernet interface, a radio interface, a Universal Serial Bus (USB)interface, or any other suitable communications interface and caninclude receivers, transmitter, and transceivers. For purposes ofclarity, a transceiver may be referred to as a receiver or a transmitterwhen referring to only the input or only the output functionality of thetransceiver. Example communication interfaces 712 may include, forexample, wired data transmission links such as Ethernet and TCP/IP. Thecommunication interfaces 712 may include, for example, wirelessprotocols for interfacing with private or public networks 714. Forexample, the network and communication interfaces 712 and protocols mayinclude interfaces for communicating with private wireless networks suchas, for example, a Wi-Fi network, one of the IEEE 802.11x family ofnetworks, or another suitable wireless network. The network andcommunication interfaces 712 may include interfaces and protocols forcommunicating with public wireless networks 712, using, for example,wireless protocols used by cellular network providers, including CodeDivision Multiple Access (CDMA) and Global System for MobileCommunications (GSM), etc. A computing device 700 may use network andcommunication interfaces 712 to communicate with hardware modules suchas, for example, a database or data store, or one or more servers orother networked computing resources. Data may be encrypted or protectedfrom unauthorized access.

According to one or more embodiments, the computing device 700 mayinclude a system bus 716 for interconnecting the various components ofthe computing device 700, or the computing device 700 may be integratedinto one or more chips such as, for example, a programmable logic deviceor an application specific integrated circuit (ASIC), etc. The systembus 716 may include, for example, a memory controller, a local bus, or aperipheral bus for supporting input and output devices 704, andcommunication interfaces 712, etc. Example input and output devices 704may include keyboards, keypads, gesture or graphical input devices,motion input devices, touchscreen interfaces, one or more displays,audio units, voice recognition units, vibratory devices, computer mice,and any other suitable user interface.

The processor 702 and memory 706 may include nonvolatile memory forstoring, for example, computer-readable instructions, data, datastructures, program modules, code, microcode, and other softwarecomponents for storing the computer-readable instructions innon-transitory computer-readable mediums in connection with the otherhardware components for carrying out the methodologies described herein.Software components may include, for example, source code, compiledcode, interpreted code, executable code, static code, dynamic code,encrypted code, or any other suitable type of code or computerinstructions implemented using any suitable methodology including, forexample, high-level, low-level, object-oriented, visual, compiled, orinterpreted programming language, etc.

These and other embodiments of the systems and methods may be used aswould be recognized by those skilled in the art. The above descriptionsof various systems and methods are intended to illustrate specificexamples and describe certain ways of making and using the systemsdisclosed and described here. These descriptions are neither intended tobe nor should be taken as an exhaustive list of the possible ways inwhich these systems can be made and used. A number of modifications,including substitutions of systems between or among examples andvariations among combinations can be made. Those modifications andvariations should be apparent to those of ordinary skill in this areaafter having read this disclosure.

The systems, apparatuses, devices, and methods disclosed herein aredescribed in detail by way of examples and with reference to thefigures. The examples discussed herein are examples only and areprovided to assist in the explanation of the apparatuses, devices,systems and methods described herein. None of the features or componentsshown in the drawings or discussed below should be taken as mandatoryfor any specific implementation of any of these the apparatuses,devices, systems or methods unless specifically designated as mandatory.For ease of reading and clarity, certain components, modules, or methodsmay be described solely in connection with a specific figure. In thisdisclosure, any identification of specific techniques, arrangements,etc. are either related to a specific example presented or are merely ageneral description of such a technique, arrangement, etc.Identifications of specific details or examples are not intended to be,and should not be, construed as mandatory or limiting unlessspecifically designated as such. Any failure to specifically describe acombination or sub-combination of components should not be understood asan indication that any combination or sub-combination is not possible.It will be appreciated that modifications to disclosed and describedexamples, arrangements, configurations, components, elements,apparatuses, devices, systems, methods, etc. can be made and may bedesired for a specific application. Also, for any methods described,regardless of whether the method is described in conjunction with a flowdiagram, it should be understood that unless otherwise specified orrequired by context, any explicit or implicit ordering of stepsperformed in the execution of a method does not imply that those stepsmust be performed in the order presented but instead may be performed ina different order or in parallel.

Reference throughout the specification to “various embodiments,” “someembodiments,” “one embodiment,” “some example embodiments,” “one exampleembodiment,” or “an embodiment” means that a particular feature,structure, or characteristic described in connection with any embodimentis included in at least one embodiment. Thus, appearances of the phrases“in various embodiments,” “in some embodiments,” “in one embodiment,”“some example embodiments,” “one example embodiment, or “in anembodiment” in places throughout the specification are not necessarilyall referring to the same embodiment. Furthermore, the particularfeatures, structures or characteristics may be combined in any suitablemanner in one or more embodiments.

Throughout this disclosure, references to components or modulesgenerally refer to items that logically can be grouped together toperform a function or group of related functions. Like referencenumerals are generally intended to refer to the same or similarcomponents. Components and modules can be implemented in software,hardware, or a combination of software and hardware. The term “software”is used expansively to include not only executable code, for examplemachine-executable or machine-interpretable instructions, but also datastructures, data stores and computing instructions stored in anysuitable electronic format, including firmware, and embedded software.The terms “information” and “data” are used expansively and includes awide variety of electronic information, including executable code;content such as text, video data, and audio data, among others; andvarious codes or flags. The terms “information,” “data,” and “content”are sometimes used interchangeably when permitted by context. It shouldbe noted that although for clarity and to aid in understanding someexamples discussed herein might describe specific features or functionsas part of a specific component or module, or as occurring at a specificlayer of a computing device (for example, a hardware layer, operatingsystem layer, or application layer), those features or functions may beimplemented as part of a different component or module or operated at adifferent layer of a communication protocol stack. Those of ordinaryskill in the art will recognize that the systems, apparatuses, devices,and methods described herein can be applied to, or easily modified foruse with, other types of equipment, can use other arrangements ofcomputing systems such as client-server distributed systems, and can useother protocols, or operate at other layers in communication protocolstacks, than are described.

It is intended that the specification and examples be considered asexemplary only, with a true scope and spirit of the invention beingindicated by the following claims.

1-20. (canceled)
 21. A method for optimizing transaction authorizationconversion rates using measured feedback, comprising: generating, by aprocessor, a transaction success model comprising authorization successfactors for each of a plurality of payment transaction parameters;determining, by the processor, one or more transaction modificationrules by applying the generated transaction success model; generating,by the processor, a modified payment transaction by using anauthorization formatting service to modify one or more parameters of apayment transaction according to the one or more transactionmodification rules; and submitting, by the processor, the modifiedpayment transaction to a financial institution for processing.
 22. Themethod of claim 21, further comprising: receiving a payment transactionauthorization result for the submitted modified payment transaction; andadding the received payment transaction authorization result and theparameters of the modified payment transaction to a database of paymenttransaction processing results.
 23. The method of claim 21, wherein themodifying one or more parameters of the payment transaction furthercomprises: comparing the parameters of the payment transaction to thegenerated authorization success factors; and modifying each parameter ofthe payment transaction where the generated authorization successfactors indicate a greater likelihood of authorization of the paymenttransaction.
 24. The method of claim 21, wherein the payment transactionparameters comprise one or more of a billing address, a cardverification value (CVV), a payment processing network, a paymentvehicle expiration date, a payment vehicle issuer token, and a merchantclassification code (MCC).
 25. The method of claim 24, wherein theauthorization success factors include an absence of one or more of thebilling address, the CVV, and the payment vehicle expiration date. 26.The method of claim 24, wherein: the merchant is associated with aplurality of MCCs, and the authorization success factors indicate alikelihood of authorization of the payment transaction associated witheach MCC among the plurality of MCCs.
 27. The method of claim 24,wherein: a plurality of payment networks are available for submittingthe modified payment transaction for processing, and the authorizationsuccess factors indicate a likelihood of authorization of the paymenttransaction associated with each payment network among the plurality ofpayment networks.
 28. The method of claim 24, wherein the modifying oneor more parameters of the payment transaction comprises providing apayment vehicle issuer token.
 29. A non-transitory computer readablemedium storing a program causing a computer to execute a method ofoptimizing transaction authorization conversion rates using measuredfeedback, the method comprising: generating, by a processor, atransaction success model comprising authorization success factors foreach of a plurality of payment transaction parameters; determining, bythe processor, one or more transaction modification rules by applyingthe generated transaction success model; generating, by the processor, amodified payment transaction by using an authorization formattingservice to modify one or more parameters of a payment transactionaccording to the one or more transaction modification rules; andsubmitting, by the processor, the modified payment transaction to afinancial institution for processing.
 30. The non-transitory computerreadable medium of claim 29, wherein the payment transaction parameterscomprise one or more of a billing address, a card verification value(CVV), a payment processing network, a payment vehicle expiration date,a payment vehicle issuer token, and a merchant classification code(MCC).
 31. The non-transitory computer readable medium of claim 30,wherein the authorization success factors include an absence of one ormore of the billing address, the CVV, and the payment vehicle expirationdate.
 32. The non-transitory computer readable medium of claim 30,wherein: the merchant is associated with a plurality of MCCs, and theauthorization success factors indicate a likelihood of authorization ofthe payment transaction associated with each MCC among the plurality ofMCCs.
 33. The non-transitory computer readable medium of claim 30,wherein: a plurality of payment networks are available for submittingthe modified payment transaction for processing, and the authorizationsuccess factors indicate a likelihood of authorization of the paymenttransaction associated with each payment network among the plurality ofpayment networks.
 34. The non-transitory computer readable medium ofclaim 30, wherein the modifying one or more parameters of the paymenttransaction comprises providing a payment vehicle issuer token.
 35. Acomputing system for optimizing transaction authorization conversionrates using measured feedback, the computing system comprising anon-transitory computer readable medium having instructions storedthereon which when executed by a processor cause the processor to:generate, by a processor, a transaction success model comprisingauthorization success factors for each of a plurality of paymenttransaction parameters; determine, by the processor, one or moretransaction modification rules by applying the generated transactionsuccess model; generate, by the processor, a modified paymenttransaction by using an authorization formatting service to modify oneor more parameters of a payment transaction according to the one or moretransaction modification rules; and submit, by the processor, themodified payment transaction to a financial institution for processing.36. The computing system of claim 35, wherein the payment transactionparameters comprise one or more of a billing address, a cardverification value (CVV), a payment processing network, a paymentvehicle expiration date, a payment vehicle issuer token, and a merchantclassification code (MCC).
 37. The computing system of claim 36, whereinthe authorization success factors include an absence of one or more ofthe billing address, the CVV, and the payment vehicle expiration date.38. The computing system of claim 36, wherein: the merchant isassociated with a plurality of MCCs, and the authorization successfactors indicate a likelihood of authorization of the paymenttransaction associated with each MCC among the plurality of MCCs. 39.The computing system of claim 36, wherein: a plurality of paymentnetworks are available for submitting the modified payment transactionfor processing, and the authorization success factors indicate alikelihood of authorization of the payment transaction associated witheach payment network among the plurality of payment networks.
 40. Thecomputing system of claim 36, wherein the modifying one or moreparameters of the payment transaction comprises providing a paymentvehicle issuer token.